A network storage appliance is a special-purpose computer that provides file service relating to the organization of information on storage devices, such as disks. The network storage appliance or filer typically accesses one or more storage volumes. A storage volume comprises physical storage devices defining an overall logical arrangement of storage space, and each volume is usually associated with its own file system. Currently available filer implementations can serve a large number of discrete volumes (150 or more, for example).
Additionally, a filer may be made more reliable and stable in the event of a system shutdown or other unforeseen problem by employing a backup memory consisting of a non-volatile random access memory (NVRAM) as part of its architecture. An NVRAM is typically a large-volume solid-state memory array (RAM) having either a back-up battery, or other built-in last-state-retention capabilities (e.g. a FLASH memory), that holds the last state of the memory in the event of any power loss to the array.
A filer includes a storage operating system that implements a file system to logically organize stored information as a hierarchical structure of directories and files. As used herein, the term “storage operating system” generally refers to the computer-executable code operable on a computer that manages data access and may, in the case of a filer, implement file system semantics. The storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows NT®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein. The set of valid file names and directory names recognized by a file system comprises its namespace. Each “on-disk” file may be implemented as a set of disk blocks configured to store information, such as text, whereas the directories may be implemented as specially formatted files in which information about other files and directories are stored.
In general, a filer may be configured to operate according to a client/server model of information delivery to thereby allow many clients to access files and directories stored on a server, e.g., the filer. In this model, the client may communicate with the filer over a computer network, such as a point-to-point link or a shared local area network, using a known protocol such as the conventional Common Internet File System (CIFS) protocol for the Microsoft® Windows™ operating system or the Network File System (NFS) protocol for UNIX-based operating systems.
More specifically, a client can locate a desired file or directory within a namespace exported by a filer. Using a recognized file system protocol, the client can send the filer an access request, such as READ, WRITE, RENAME or REMOVE, along with a unique file handle identifier for the desired file or directory. The filer uses the file handle to locate the requested file or directory within a file system and typically returns information appropriate for the client access request or returns an error code explaining why the request could not be completed. A file access request to the filer may also originate from a local user or application instead of from a remote client. In this case, the local user or application can navigate the file system namespace and submit a file access request along with a file handle identifier for a desired file or directory.
Because a filer can handle file access requests from a large number of sources, ranging from remote clients to local users and applications, access to files and directories within the filer is often restricted to prevent an unauthorized client, user or application from accessing protected information. An example of restricted files and directories within a filer may include, but are not limited to, configuration files, system files, support files and temporary files not intended to be globally accessible. A protected file or a restricted file used herein refers to any file or directory having restricted file access.
A number of conventional methods are used for restricting access to files and directories in a file system. In Unix-based operating systems, file access is typically restricted by associating an access mode with each file and directory. The access mode grants a selected combination of read/write/execute (rwx) permissions to different categories of users. FIG. 1 illustrates an exemplary file permission 100 for a Unix file named “testfile” that includes, inter alia, sets of access mode flags 110, 120 and 130, a user identifier 140, a group identifier 150 and a file name 160. Access to the file is restricted by access mode flags 110, 120 and 130 that respectively define the rwx file permissions for a user, “jdoe,” a group of users, “engineering,” and all other users, “other.” In Microsoft® DOS-based operating systems, file access is restricted according to file attributes associated with each file and directory. For example, FIG. 2 illustrates file attributes 200 for file 220, “IO.SYS,” located on a disk labeled “CA” as described by path 230. As shown, IO.SYS has file attributes 210 indicating it is a read-only file, “R,” for use by the operating system, “S,” and hidden from a user-accessible namespace, “H.” In the Microsoft® Windows NT™ operating system, an access control list associated with each file and directory grants access permissions to different categories of users. As shown in FIG. 3, an access control list 300 is associated with the file “Frog.exe.” The location of the file 320 and the owner of the file 340 are listed in a header portion of the access control list, whereas access permissions 360 are explicitly described separately for individual users, e.g. “Paul,” and groups of users, e.g. “Marketing.” Typically, access control lists additionally include a field 380 for setting file and directory permissions.
Despite utilizing the conventional file security techniques described above, files with special access restrictions are often “visible” in the user-accessible namespace of a file system. For instance, although access to system files may be restricted to specific modules within a filer's storage operating system, those files may still be seen by any user or application that can navigate the file system's namespace. Therefore, there is a need to effectively “hide” restricted files and directories in a file system namespace to assure they cannot be improperly tampered with by unauthorized clients, users and applications.
Past techniques for hiding file names in a file system namespace have included assigning a hidden attribute to restricted files and directories indicating they should not automatically be displayed in a user-accessible namespace. For example, file systems implemented by Microsoft® DOS™-based operating systems assign attributes to files and directories to indicate whether the file is e.g., read-only, hidden, archived, system, or compressed. Unix-based operating systems do not use hidden attributes, but instead automatically hide file names and directories beginning with a “dot.” Although previous methods have hidden the names of protected files and directories in a file system namespace, most storage operating systems have allowed users to view hidden files and directories by setting appropriate flags in their file access request. For instance, the DOS command “dir *.*” and the Unix command “ls -a” effectively allow a user to list both hidden and non-hidden files. Therefore, past techniques for hiding protected files and directories suffer the disadvantage of allowing users to easily locate hidden files in a user-accessible namespace.
Yet other approaches to hiding files and directories in a file system have been employed. For example, the Data ONTAP™ storage operating system, available from Network Appliance, Inc. of Sunnyvale, Calif., may implement a Write Anywhere File Layout (WAFL™) file system such that hidden files and directories in a WAFL volume are not directly located in the user-accessible namespace.
Broadly stated, the on-disk format representation of the WAFL file system is block-based using, e.g., 4 kilobyte (KB) blocks and using inodes to describe the files. An inode is a data structure used to store information, such as metadata, about a file. That is, the information contained in an inode may include, e.g., ownership of the file, access permission for the file, size of the file, file type and location of the data for the file on disk. The WAFL file system uses a file handle, i.e., an identifier that includes an inode number, to retrieve an inode from disk. The WAFL file system also uses files to store metadata describing the layout of its file system. These metadata files include, among others, an inode file that describes files and directories stored in the file system. The on-disk format structure of the WAFL file system, including the inodes and inode file, is disclosed and described in commonly assigned U.S. Pat. No. 5,819,292 entitled Method for Maintaining Consistent States of a File System and for Creating User-Accessible Read-Only Copies of a File System by David Hitz et al., issued on Oct. 6, 1998 and expressly incorporated herein by reference.
The WAFL file system can “hide” protected files and directories by pre-allocating their inode numbers outside the user-accessible namespace. In this way, clients, users and applications navigating the file system cannot directly locate inodes of these files. For instance, a protected file having a pre-allocated inode outside the user-accessible namespace may contain configuration data that should only be accessed by a specific application. Since only the storage operating system and the specific application know which inode number was assigned to the file, unauthorized clients, users and applications cannot create a valid file handle to submit file access requests for the protected file. Thus, unlike most conventional storage operating systems, access to hidden files is restricted to only those users having knowledge of the pre-allocated inode numbers of the protected files.
However, the method described above for hiding files in a file system may not scale well, and is inconvenient, when new files and directories need access protection. For instance, every time a new protected file is added to the file system, the storage operating system must be re-compiled to pre-allocate an inode number for the new file, then the pre-allocated inode number must be communicated to clients, users and applications permitted to access the protected file. Furthermore, there may be a limited number of reserved inodes available for pre-allocation.
Therefore, it is generally desirable to implement a file system capable of hiding protected files and directories outside its user-accessible namespace so the hidden files are accessible only to authorized clients, users and applications. Advantageously, the storage operating system should not require complicated function calls to access protected files and directories hidden in its file system and should scale easily when hidden files are added and removed.